1. Field of the Invention
The present invention generally relates to a system and method for computer program development, program development tools, and program development environments. More particularly, the present invention relates to means for fixing program errors as provided by program development tools, and more particularly, to a system and method that focuses on the practice of program development in building a program across a number of programming tools, whereupon the errors are reviewed, and the errors are fixed. The present invention includes, for example, a method by which errors during program development are better identified and resolved through error coordination and immediate interactive resolution, improving in time and efficacy the program development process.
2. Description of the Conventional Art
The relationship between programmer and programming tools has essentially remained unchanged in this following aspect: the user executes a programming tool, for example, a compiler, against a body of programming artifacts such as source code or binary output from other phases. The practitioner then reviews potentially extensive error summaries, and selectively and appropriately fixes errors through such means as a text editor. Typically, this applies to the application of one tool at a time, and in many cases, to a single programming artifact, e.g. source file, at a time.
The issue being raised, in the context of the technology so described, is that error management by programming tools or their encompassing environment has been negligible. Typically, as each tool runs, errors are gathered into a list, and simply displayed in total to the user, and for the user to ferret out. As a result, practitioners face the following typical problems:                Many errors indicate simple omissions, such as missing include files. However, a large number of errors are generated based on that missing information, as the compiler carries to completion.        Many variable naming issues have a simple solution. So, when an illegal or conflicting name is used in a program, it is only post-facto. It would be better if a name could be checked for legality or conflict before or during compilation. Similar situations occur in, for example, renaming a C++ class, a variable, a method, a data field, etc.        Linker problems with unresolved symbols often are related to unspecified libraries. Associating the missing routine to a library is often difficult. At the same time, the practitioner deals with this in the context of all missing library messages, which is difficult to deal with.        Linker errors, such as unresolved symbols, are often based on misspellings or case problems. Since linking does not deal with source code, there is little help in relating the error to the source, especially in the case of name mangling, as often found in C++.        
Other classes of errors can be classified as limitations which arise generally from configurations and ancillary input leveraged against individual tools participating in a program development. Such configuration information includes, but is not restricted to, error filtering settings, levels of optimization, and paths to source and libraries. These limitations can be further decomposed into either functional or non-functional limitation errors.
For purposes of this disclosure, functional errors include, for example, incorrect specifications to the development tools such as incorrect files, library locations, or general tool settings related to the specific program development.
For purposes of this disclosure, non-functional errors derive from tool behavioral anomalies despite correct input specification. These can include, for example, performance, excessive computation, etc., which are usually remediated through alternative configurations. For example, optimization levels for compilation may be technically correct, but incur significant computation overhead. Optimization at lesser levels may be sufficient for the developing application while speeding up the build compilations.
In many of these cases, the end user typically endures a potentially large set of repetitious, predictable, but unrelated errors. In many cases, problems span programming tools, and in such cases, the practitioner must deduce that the fix should be applied at earlier phases.